Java知识体系

Appearance

OAuth 方式进行授权 - 概念理解

一个生动的比喻：酒店门卡 ​

假设你去一个酒店入住，你想让朋友帮你去房间拿个东西，但你不想给他你的房间钥匙（主密码），也不想他每次来都找你开门。

  1. 你（资源所有者） 去前台（授权服务器）。
  2. 你告诉前台：“我想给我的朋友（第三方应用） 开一张能进入我房间（受保护资源） 的门卡，但只能进出一次，并且只能开房门，不能开迷你吧。”
  3. 前台说：“可以，请让你的朋友先来我这里登记一下。”
  4. 你的朋友来到前台，前台向你确认（征得用户同意）：“您是否授权这位朋友获得一张限时门卡？” 你确认“是”。
  5. 前台核实了朋友的身份后，并没有直接给他门卡，而是给了他一个凭证单（授权码 Authorization Code）。
  6. 你的朋友拿着这个凭证单，再次回到前台。
  7. 前台确认凭证单有效后，才发放了一张限时、限功能的门卡（访问令牌 Access Token） 给他。
  8. 你的朋友拿着这张门卡，就可以直接去房间门口（资源服务器） 刷卡进门了，无需再经过你的同意。

这个“凭证单”就是 OAuth 流程安全的关键。

OAuth 2.0 的核心角色 ​

在正式讲流程前，先明确四个核心角色：

  1. 资源所有者 (Resource Owner)： 拥有受保护数据的人，即用户。在比喻中就是“你”。
  2. 客户端 (Client)： 想要访问用户数据的第三方应用。在比喻中就是“你的朋友”。
  3. 授权服务器 (Authorization Server)： 专门负责处理授权、验证用户身份、并颁发令牌的服务器。这是 OAuth 流程的核心。在比喻中就是“酒店前台”。
  4. 资源服务器 (Resource Server)： 存放用户受保护数据的 API 服务器。客户端最终拿着令牌来这里取数据。在比喻中就是“房间门”以及门背后的房间。通常授权服务器和资源服务器属于同一个服务商（例如 Google），但在逻辑上是分开的。

最常用的流程：授权码模式 ​

这是最安全、最完整的流程，用于有后端的 Web 应用。其流程图如下：

mermaid
sequenceDiagram
    participant User as 用户 (资源所有者)
    participant Client as 第三方应用 (客户端)
    participant AuthServer as 授权服务器
    participant ResourceServer as 资源服务器

    Note over User, Client: 1. 初始化授权请求
    Client->>User: 点击“通过Google登录”

    Note over User, AuthServer: 2. 用户认证与授权
    User->>AuthServer: 被重定向到授权服务器
    AuthServer->>User: 要求登录并询问是否授权
    User->>AuthServer: 登录并同意授权

    Note over AuthServer, Client: 3. 颁发授权码
    AuthServer->>Client: 通过重定向返回授权码

    Note over Client, AuthServer: 4. 用授权码换取访问令牌
    Client->>AuthServer: 发送授权码和客户端密钥<br>请求访问令牌
    AuthServer->>Client: 返回访问令牌 (和刷新令牌)

    Note over Client, ResourceServer: 5. 使用访问令牌调用API
    Client->>ResourceServer: 在请求头中携带访问令牌
    ResourceServer->>Client: 返回受保护的资源数据

参考链接